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M. DISEGNO 



Viene descritto un metodo per la gestione delle comunicazioni di eventi (quali 
ad es. allarmi) tra entita di elaborazione di tipo Agent e Manager, in particolare per 
protocolli di comunicazione tipo "connection-less", in un sistema di gestione di rete di 
telecomunicazioni, che attua una procedure atta ad incrementare I'affidabilita del 
sistema di comunicazione di eventi, per cui I'Agent spedisce al Manager notifiche di 
allerta per segnalare I'insorgenza di nuovi eventi. Le notifiche di allerta possono 
essere spedite ad intervalli di tempo fissi, e/o dopo un certo numero di eventi generati. 
II Manager pu6 comunque mantenere un meccanismo di "time-out polling" per la 
lettura periodica degli eventi nell'Agent, ed inoltre I'Agent pud spedire al Manager le 
notifiche di eventi di maggiore urgenza o importanza (fig. 1). 
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DESCRIZIONE 



La presente invenzione riguarda un metodo per la gestione delle comunicazioni 
di eventi tra entita di elaborazione di tipo Agent e Manager in un sistema di gestione di 
rete di telecomunicazioni, in particolare per protocolli di comunicazione tipo 



Come noto, un sistema di gestione di rete di telecomunicazioni comprende 
entita di elaborazione, denominate nel seguito Agent, fisicamente dislocate negli 
element! di rete, ed almeno un'entita di elaborazione, denominate nel seguito 
Manager, in funzione di controllo normalmente centralizzato. Dette entita Agent e 
Manager scambiano informazioni tramite protocolli di comunicazione. 

E' prevalente I'uso di tipi di protocolli di comunicazione definiti nel seguito 
"connection-less", cioe protocolli che non prevedono di instaurare connessioni fisiche 
o logiche tra le varie entita Agent e Manager per lo scambio di informazioni. Queste 
informazioni vengono inviate sotto forma di messaggi solo quando necessario, cosi 
ottimizzando I'utilizzo delle risorse del canale di trasmissione. 

Esistono vari tipi di messaggi scambiati tra Agent e Manager e viceversa: ad 
esempio un tipo e un'interazione richiesta-risposta per cui il Manager invia una 
richiesta ad un Agent che di conseguehza risponde; un altro tipo e ancora 
un'interazione richiesta-risposta tra due entita manager. 

In questi casi il flusso informativo e comunque sotto il controllo del Manager 
che a fronte di un messaggio di richiesta si aspetta di ricevere di conseguenza un 
determinato tipo di messaggio di risposta. 

Un ulteriore tipo noto di messaggi e quello che consente di trasmettere 
informazioni su eventi, quali ad esempio la segnalazione di allarmi, dalle entita Agent 



"connection-less". 
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al Manager. In questi casi invece il Manager non sa prevedere quando un messaggio 
e spedito dall'Agent, poiche viene spedito non gia con cadenza regolare e quindi 
prevedibile, e su richiesta del Manager, ma invece solo quando necessario, in tempi 
non prestabiliti e decisi dall'Agent. Inoltre I'Agent non si aspetta risposte del tipo 
"conferma di ricezione" dal Manager. 

II problema che quindi nasce e la possibile perdita dei messaggi relativi a questi 
eventi, in alcuni casi, come quando si creano code di messaggi eccessive, oppure 
perdita di connessione di rete, o di mancata risposta del Manager. 

Una parziale risoluzione di questi problemi puo essere attuata tramite I'uso 
della nota procedura di "time-out polling": il Manager legge periodicamente la lista 
degli eventi che I'Agent memorizza al suo interno. 

Questa procedura nota pero non e ancora scevra da inconvenienti, in quanto, 
se la coda di messaggi diventa eccessiva nell'Agent, tra una richiesta del Manager e 
la successiva, c'e il rischio che una parte dei messaggi venga persa per "over-flow" 
delle capacita di memoria nell'Agent. 

Pertanto scopo della presente invenzione e quello di superare tutti gli 
inconvenienti suddetti e di indicare un metodo per la gestione delle comunicazioni di 
eventi (quali ad es, allarmi) tra entita di elaborazione di tipo Agent e Manager in un 
sistema di gestione di rete di telecomunicazioni, in particolare per protocolli di 
comunicazione tipo "connection-less", che attua una procedura per cui I'Agent 
spedisce al Manager notifiche di allerta per segnalare I'insorgenza di nuovi eventi. 

Le notifiche di allerta possono essere spedite ad intervalli di tempo fissi, oppure 
dopo un certo numero di eventi generati, oppure con una combinazione di queste due 
tecniche. 

Tutti gli eventi generati vengono memorizzati in una memoria eventi dell'Agent, 
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per evitare di perderli per inaffidabilita del tipo di protocollo usato. Inoltre I'Agent pud 
spedire comunque al Manager le notifiche relative agii eventi di maggiore urgenza o 
importanza, appena verificatisi. 

Per conseguire tali scopi la presente invenzione ha per oggetto un metodo per 
la gestione delle comunicazioni di eventi tra entita di elaborazione di tipo Agent e 
Manager, nonche un sistema di gestione di rete di telecomunicazioni ed una 
corrispondente rete cosi modificate in modo da includere detto metodo, come meglio 
descritto nelle rivendicazioni, che formano parte integrante delta presente descrizione. 

II metodo per la gestione delle comunicazioni di eventi oggetto delPinvenzione 

presenta numerosi vantaggi. 

II Manager puo comunque mantenere un meccanismo di "time-out polling", 
come sopra definito, per la lettura periodica degli eventi nell'Agent, in quanto la 
procedure di notifica allarmi in accordo con I'invenzione non e conflittuale con quella di 
polling e si puo sommare a questa. 

II Manager puo scoprire la presenza di un elevato numero di eventi memorizzati 
nelKAgent anche prima della scadenza del suo time-out, e quindi potra leggere detti 
eventi nell'Agent prima che la memoria dell'Agent vada in eventuale "over-flow" 
perdendo informazione. 

La dimensione della memoria eventi e critica per I'Agent. Quindi usando il 
meccanismo oggetto dell'invenzione si incrementa I'affidabilita di tutta la procedura. La 
presenza della memoria eventi e infatti necessaria a causa del comportamento del 
protocollo di tipo connection-less usato, in modo da essere sicuri di non perdere 
eventi, mentre il meccanismo di allerta riduce i problemi di gestione delle condizioni di 
memoria piena e di "bursty alarms" (tanti eventi allarmi generati in un tempo molto 
breve). 
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Ulteriori scopi e vantaggi della presente invenzione risulteranno chiari dalla 
descrizione particolareggiata che segue di un esempio di reatizzazione della stessa e 
dai disegni annessi dati a puro titolo esplicativo e non limitativo, in cui: 

nella figura 1 e evidenziato uno schema di principio del funzionamento del 

metodo di gestione delle comunicazioni di eventi tra elementi MANAGER e 

AGENT oggetto della presente invenzione; 

nella figura 2 sono evidenziati esempi di evoluzione temporale delle notifiche di 
allerta previste dal metodo oggetto della presente invenzione. 
In figura 1, Mediante un meccanismo di interrogazione POLLING di per se noto, 
il Manager interroga periodicamente I'Agent per ricevere il contenuto degli oggetti LOG 
ed APT, che costituscono le memorie eventi, e memorizzarli al suo interno: questi 
oggetti sono costituiti da aree di memoria contenenti gli eventi che I'Agent rileva, come 
ad esempio gli allarmi, e che devono essere comunicati al Manager. LOG contiene 
tutte le informazioni di insorgenza e cancellazione degli eventi come archivio storico, 
mentre APT contiene solo gli elementi ancora attivi. 

II protocollo connection-less utilizzato e il noto SNMP (Simple Network^© 
Management Protocol), e la sintassi usata per la programmazione e quella defiritta^ # !, '' HI ' J>1 
dallo standard IETF (Internet Engineering Task Force). 

Questa sintassi prevede per esempio di utilizzare macro-istruzioni tipo GET pert^ iQvrr.\f ; 
la procedura di Polling, mediante le quali il Manager chiede all'Agent di inviare gli 
eventi memorizzati in LOG e APT: I'Agent li invia sotto forma di messaggi conformati 
in accordo con il protocollo usato. 

Oltre a questa procedura sistematica, in accordo con la presente invenzione, 
I'Agent spedisce notifiche di allerta per evidenziare I'insorgenza di nuovi eventi, quali 
allarmi. 
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Queste notiftche di allerta possono essere spedite ad intervalli di tempo fissi 

ALERT TIME-OUT, oppure dopo un certo numero di eventi generati ALERT FREQ- 
COUNT, oppure con una combinazione di questi due modi. 

II Manager pud defmire il periodo di time-out e/o la frequenza, nel senso di 
numero di eventi, che I'Agent deve contare prima di spedire la nuova notifica di allerta. 

L'Agent pud riazzerare (reset) sia il periodo di time-out che il contatore di 
frequenza ogni volta che una notifica di allerta e spedita al Manager. 

Se non ci sono nuovi eventi tra due notifiche successive, I'Agent pud evitare di 
spedire I'ultima notifica, per non impegnare risorse trasmissive inutilmente. 

L'approccio sopra descritto riduce la trasmissione di informazione inutile. 
Questo meccanismo di notifica di allerta pud essere applicato a tutti i tipi di 
notifiche, come ad esempio gli allarmi, ed altre usate dall'Agent per comunicare 
modifiche alia sua configurazione interna. Cid stimola il Manager ad effettuare una 
lettura degli eventi memorizzati in Agent senza attendere la scadenza del time-out 
della procedura di polling, evitando di perdere eventi. Queste letture ulteriori da parte 
del Manager possono essere eseguite con la stessa procedura prevista per il polling, 
azzerando o meno il time-out del polling normale: quindi il successivo "time-out 
polling" pud essere eseguito dal Manager alia scadenza normale (la lettura 
conseguente alia notifica dell'Agent si somma a quelle regolari la cui cadenza non 
viene modificata), oppure riazzerando il periodo di time-out dopo la lettura 
conseguente alia notifica dell'Agent (la lettura conseguente alia notifica dell'Agent 
sostituisce quella regolare). 

Inoltre I'Agent pud spedire comunque al sistema di gestione le notifiche di 
allerta di tipo URGENT, cioe le notifiche di maggiore urgenza o importanza non 
appena si verificano, in modo che il Manager possa decidere immediatamente le 
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azioni da compiere. Si puo quindi costruire un oggetto "filtro" che contiene relenco 
deglieventi urgenti: I'Agent verifica I'urgenza di ogni evento confrontandolo con il filtro. 

La struttura generale dei messaggi contenenti le notifiche di allerta e/o le 
notifiche urgenti, nonche la procedura di inoltro messaggi sono di per se note e come 
previste dal protocollo di comunicazione usato, come ad es. SNMP. 

La principale informazione contenuta nella notifica di allerta e I'dentificatore 
dell'ultimo evento generato dall'Agent, in modo che il Manager possa identificare 
univocamente I'ultima notifica. II Manager puo cosi controllare se detta notifica 
corrisponde a quella eventualmente gia presente in esso; altrimenti avvia la procedura 
di lettura in Agent. 

La notifica di allerta non necessita di essere essa stessa memorizzata 
nell'Agent. 

Nel seguito si descrive un esempio di meccanismo di allerta che usa il 
linguaggio del protocollo SNMP, ma il meccanismo si intende applicabile a tutti i 
protocolli di tipo connection-less in cui sono definiti messaggi autonomi dall'Agent al 
Manager. 

La struttura della notifica che I'Agent SNMP spedisce al Manager dipende dal 
tipo di evento. La relativa macro-istruzione SNMP "Trap" o "Notification" e composta 
da un nome notifica e dalle seguenti clausole: 

Oggetti: definisce una sequenza ordinata di possibili oggetti quali: "SNMP 

Instance" che identifica I'oggetto che ha generato I'evento, e "gravita" 

dell'evento; 

Status: indica se questa definizione e corrente (attuale) o supportata per 
compatibita con versioni precedenti; 

Descrizione: contiene una definizione testuale del significato della notifica. 
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Quindi la notifica di allerta avra la seguente struttura: 

- Nome Notifica: e I'identificatore di oggetto (OID) della notifica SNMP; 

Oggetti di notifica SNMP: contiene la lista di oggetti necessari per definire 
Tinformazione usata dal sistema di gestione. Questi oggetti sono relativi all'ultimo 
evento generato e lo identificano univocamente, e rappresentano: 

- Identificatore di Notifica: identificatore univoco della notifica; 

- Tempo di Generazione di notifica: istante di generazione dell'evento dell'ultima 

notifica generata. 

L'esempio seguente di oggetto notifica-di-allerta e scritto usando lo standard di 
sintassi IETF noto: 

tsdimAlertNotification NOTIFICATION-TYPE 
OBJECTS { tsdimEventNotificationld, 

tsdimEventTime } 
STATUS current 
DESCRIPTION 

"Indicates an alert notification used by Agent to highlight to the 

managing systems the creation of new events." 
::= {tsdimSupportMibObject 22 } 

La notifica di allerta non ha bisogno di avere associati ad essa nella clausola 
oggetti un "SNMP Instance Identifier" ed una "gravita" di evento che consentono di 
individuare TAgent, poiche il detentore di questa notifica e sempre I'Agent ed il sistema 
di gestione e in grado di scoprire quale Agent I'ha generata. Inoltre la notifica 
individuata dai suddetti campi "Identificatore di Notifica" e "Tempo di Generazione di 
notifica" puo essere individuata dal sistema di gestione negli oggetti APT e LOG. 

La figura 2 descrive esempi di evoluzione temporale delle notifiche di allerta. 
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Le notifiche di allerta possono essere spedite ad interval!! di tempo fissi ALERT 
TIME-OUT, e/o dopo un certo numero di eventi generati ALERT FREQ-COUNT. Si 
pud pure usare una combinazione di queste due tecniche. 

Come gia detto, il Manager definisce il periodo di time-out e/o la frequenza delle 
notifiche, nel senso di numero di eventi che I'agente deve contare prima di spedire la 
nuova notifica di allerta. 

In fig. 2 nel diagramma temporale EVENTS si evidenzia un esempio di 
successione temporale di eventi 1, 15 generati e memorizzati nell'Agent. 

Secondo il modo di spedizione ad intervalli di tempo fissi (ALERT TIME-OUT), 
le notifiche di allerta vengono inviate ad intervalli regolari T1, T2, ... T6 recando 
I'informazione deH'ultimo evento verificatosi: in T1 I'evento e il 2, in T2 e 5, in T3 e 7, e 
cosi via. La notifica corrispondente al tempo T4 potrebbe non essere spedita poiche 
non si verificano eventi tra i tempi T3 e T4, e quindi I'ultimo evento al tempo T4 e 
ancora il numero 7. 

Secondo il modo di spedizione dopo un certo numero di eventi generati (ALERT 
FREQ-COUNT), le notifiche di allerta vengono inviate ogni N eventi verificatisi: in 
figura ad esempio ogni tre eventi: quando si verifica I'evento 3 (ALM-ID=3), poi 6 
(ALM-ID=6)„ poi 9 (ALM-ID=9), e cosi via. 

Secondo il modo di spedizione misto (ALERT MIXED), si attua una 
combinazione dei due modi sopra descritti, in modo che la prossima notifica di ^rfa^ 
sara spedita o dopo N eventi successivi generati (ALERT FREQ-COUNT)horalla^^ 
scadenza dell'intervallo fisso (ALERT TIME-OUT), a seconda di quello che si venfiea 
prima, azzerando in continuo i due contatori di tempo e di frequenza, per evitare un 
doppio messaggio di notifica con la stessa informazione. 

In figura ad es., la sequenza e: T1, ALM-ID=5, T2, T3, ALM-ID=10, ALM-ID=13, 



e cosi via. La notifica in T3 in realta non verra inviata, poiche tra T2 e T3 non si 
verificano nuovi eventi. 

Dalla descrizione su riportata risulta quindi evidente come si puo ottenere un 
sistema di gestione di rete di telecomunicazioni e la relativa rete modificati 
opportunamente al fine di includere le operazioni previste dal metodo di gestione delle 
comunicazioni di eventi oggetto dell'invenzione. 

Dalle conoscenze di base e dalla descrizione sopra riportata il tecnico del ramo 
e in grado di realizzare I'oggetto dell'invenzione. 

La presente invenzione puo vantaggiosamente essere realizzata tramite un 
prograrnma per elaboratore comprendente mezzi di codifica di programma adatti ad 
eseguire una o piu delle fasi del metodo quando detto programma viene fatto girare su 
un elaboratore. Pertanto I'ambito di protezione si intende esteso a tale programma per 
elaboratore oltre che ad un mezzo ieggibile tramite elaboratore avente un messaggio 
registrato su di esso, detto mezzo Ieggibile tramite elaboratore comprendendo mezzi 
di codifica di programma adatti ad eseguire una o piu delle fasi del metodo quando 
detto programma viene fatto girare su un elaboratore. 

Molti cambiamenti, modifiche, variazioni della presente invenzione diverranno 
chiari a coloro esperti della tecnica dopo aver considerate la presente descrizione e gli 
annessi disegni che illustrano sue forme di realizzazione preferite. Tutti tali 
cambiamenti, modifiche, variazioni che non si allontanano dallo spirito e dall'ambito 
dell'invenzione sono considerati coperti dall'invenzione. 
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RIVENDICAZIONI 

1 Metodo per la gestione delle comunicazioni di eventi tra entita di elaborazione 
di tipo Agent e Manager, in un sistema di gestione di rete di telecomunicazioni, 
utilizzante un protocollo di comunicazione tra Agent e Manager di tipo connection-less, 
caratterizzato dal fatto che prevede una fase in cui I'Agent spedisce al Manager 
notifiche di allerta per segnalare I'insorgenza di nuovi eventi. 

2. Metodo secondo la rivendicazione 1 , caratterizzato dal fatto che dette notifiche 
di allerta possono essere spedite ad intervalli di tempo fissi (ALERT TIME-OUT). 

3. Metodo secondo la rivendicazione 1 , caratterizzato dal fatto che dette notifiche 
di allerta possono essere spedite dopo un certo numero di eventi generati (ALERT 
FREQ-COUNT). 

4. Metodo secondo la rivendicazione 2 o 3, caratterizzato dal fatto che dette 
notifiche di allerta possono essere spedite secondo una combinazione dei due detti 
modi ad intervalli di tempo fissi e dopo un certo numero di eventi generati, in modo 
che la prossima notifica di allerta sara spedita o dopo N eventi successivi generati o 
alia scadenza di detto intervallo di tempo fisso, a seconda del modo che si verifica 
prima nel tempo. 

5. Metodo secondo una qualsiasi delle rivendicazioni da 2 a 4, caratterizzato dal 
fatto che il Manager definisce detto intervallo di tempo fisso, oppure detto numero di 
eventi generati. 

6. Metodo secondo la rivendicazione 5, caratterizzato dal fatto che I'Agent puo 
riazzerare (reset) detto intervallo di tempo fisso, oppure detto numero di eventi 
generati, ogni volta che una notifica di allerta 6 spedita al Manager. 

7. Metodo secondo una qualsiasi delle rivendicazioni precedenti, caratterizzato 
dal fatto che se non ci sono nuovi eventi I'Agent non spedisce nuove notifiche. 



8. Metodo secondo una qualsiasi delle rivendicazioni precedent!, caratterizzato 
dal fatto che detta notifica di allerta contiene rinformazione che identifica I'ultimo 
evento generato dall'Agent. 

9. Metodo secondo una qualsiasi delle rivendicazioni precedenti, caratterizzato 
da! fatto che la notifica di allerta avra la seguente struttura: 

- Nome Notifica: identificatore di oggetto (OID) della notifica SNMP; 

- Oggetti di notifica: contiene la lista di oggetti necessari per definire rinformazione 
usata dal Manager, detti oggetti rappresentando: 

- Identificatore di Notifica: identificatore univoco della notifica; 

- Tempo di Generazione di notifica: istante di generazione deirevento dell'ultima 

notifica generata. 

10. Metodo secondo una qualsiasi delle rivendicazioni precedenti, caratterizzato 
dal fatto che prevede ulteriormente le fasi di: 

memorizzazione degli eventi nelPAgent (LOG, APT); 

- lettura periodica da parte del Manager (POLLING) di detti eventi nelPAgent. 

1 1 . Metodo secondo la rivendicazione 10, caratterizzato dal fatto che il Manager 
effettua una lettura degli eventi memorizzati in Agent dopo aver ricevuto dette notifiche 
di allerta, senza attendere la scadenza di detta lettura periodica. 

12. Metodo secondo una qualsiasi delle rivendicazioni precedenti, caratterizzato 
dal fatto che prevede ulteriormente la fase in cui I'Agent spedisce al Manager notifiche 
urgenti, relative ad eventi di maggiore urgenza o importanza. 

13. Sistema di gestione di rete di telecomunicazioni, caratterizzato dal fatto che 
comprende un metodo per la gestione delle comunicazioni di eventi tra entity di 
elaborazione di tipo Agent e Manager come in una qualsiasi delle rivendicazioni da 1 
a 12. 




14. Rete di telecomunicazioni caratterizzata dal fatto di comprendere un sistema di 
gestione come in una qualsiasi delle rivendicazioni da 1 a 13. 

1 5. Programma per elaboratore comprendente mezzi di codifica di programma 
adatti ad eseguire una o piu delle fasi delle rivendicazioni 1-12 quando detto 
programma viene fatto girare su un elaboratore. 

16. Mezzo leggibile tramite elaboratore avente un messaggio registrato su di 
esso, detto mezzo leggibile tramite elaboratore comprendendo mezzi di codifica di 
programma adatti ad eseguire una o piu delle fasi delle rivendicazioni 1-12 quando 
detto programma viene fatto girare su un elaboratore. 

p.p. ALCATEL 
II Mandatario 
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